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Foreword 



This technical description has been produced by TIP 1. 

The present document is a description of the Cellular Text Telephone Modem solution for reliable transmission of a text 
telephone conversation via the speech channel of cellular or PSTN networks 

The contents of the present document are subject to continuing work within 3GPP and may change following formal 
3GPP approval. Should the 3GPP TSG modify the contents of this TD, it will be re-released by the 3GPP TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to 3GPP for information; 

2 presented to 3GPP for approval; 

3 Indicates 3GPP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



This Technical Specification (TS) concerns the Cellular Text Telephone Modem (CTM). CTM allows reliable 
transmission of a text telephone conversation alternating with a speech conversation through the existing speech 
communication paths in cellular mobile phone systems. This reliability is achieved by an improved modulation 
technique, including error protection, interleaving and synchronization. Together with recommendations ITU-T V.18 
and T.140, CTM may serve for worldwide applications in text telephony. 

A general overview and explanations of possible implementation architectures is provided. CTM is intended for use in 
end terminals (on the mobile or fixed side) and within the network for the adaptation between CTM and existing 
traditional text telephone standards. 

The CTM transmitter is fully specified and a bit exact C-code reference is provided. An implementation of an example 
CTM receiver is also described. 



2 Normative References 

This TS incorporates by dated and undated reference, provisions from other publications. These normative references 
are cited at the appropriate places in the text and the publications are listed hereafter. For dated references, subsequent 
amendments to or revisions of any of these publications apply to this TS only when incorporated in it by amendment or 
revision. For undated references, the latest edition of the publication referred to applies. 

[1 ] 3GPP TS 26.231 , Cellular Text Telephone Modem (CTM), Minimum Performance 

Specification 

[2] ITU-T Recommendation V.18, Operational and interworking requirements for DCEs 

operating in the text telephone mode, November 2000 

[3] 3GPP TS 26.230, Cellular Text Telephone Modem (CTM); Transmitter Bit Exact 

C-Code 

[4] ANSI TIA/EIA-825, A Frequency Shift Keyed Modem for use of the Public Switched 

Telephone Network, March 2000 

[5] ITU-T T.140, Protocol for multimedia application text conversation, Feb. 1998 

[6] ISO/IEC 1 0646-1 , Information technology - Universal Multiple-Octet Coded 

Character Set (UCS) - Parti : Architecture and Basic Multilingual Plane 

[7] ITU-T H.248, Annex F, Text Telephony, Text Conversation, Fax and Call 

discrimination packages (Nov., 2000) 

3 Definitions and Abbreviations 
3.1 Definitions 

Cellular Text Telephone Modem Modem (consisting of transmitter and receiver) that allows the reliable 
transmission of text via the speech channel of cellular phone systems or PSTN networks 

Baudot Code Modem signal and character coding scheme of the North American Text Telephone, as specified in 
ITU-T V.18, Annex A.l ("5-bit operational code") and in ANSI TIA/EIA-825 [2, 4] 

Text Telephone Code Modem signal and character coding scheme of any of the PSTN Text Telephone types 
supported by the harmonizing ITU-T Recommendation V.18 [2] 
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3.2 Abbreviations 

For the purposes of this TS, the following abbreviations apply: 

BP Band Pass 

CER Character Error Rate 

CTM Cellular Text Telephone Modem 

FCC Federal Communications Commission 

EEC Forward Error Correction 

GSM Global System for Mobile communications 

HCO Hearing Carry Over Alternating transmission of speech and text. 

ITU-T International Telecommunication Union - Telecommunication standardization sector (former 

CCITT) 

LP Low Pass 

PCM Pulse Code Modulation 

PSTN Public Switched Telephone Network 

TTY Text Telephone 

UCS Universal Multiple-Octet Coded Character Set 

UMTS Universal Mobile Telecommunications Systems 

VAD Voice Activity Detection 

VCO Voice Carry Over alternating transmission of speech and text 



General 



Deaf, hard of hearing, and speech-impaired persons have been using specific Text Telephone (referred to as TTY in 
North America) equipment in the fixed network for many years to transmit text and speech through ordinary speech 
traffic channels. Modern digital cellular systems, however, do not provide satisfactory character error rates for text 
transmitted in the speech channel with the traditional modulation developed for the fixed network. The FCC under the 
US Government has required an urgent solution for all emergency (911) calls for one specific text telephone protocol 
called Baudot Code. This TS addresses these FCC requirements, and specifies a solution for the GSM and UMTS and 
potentially other cellular technologies. The goal is to provide a solution that can support all traditional text telephony 
systems worldwide. Internationally, PSTN text telephony is standardized in ITU-T V.18 [2] and ITU-T T.140 [5]. 



5 The Problem 

Due to the fact that digital cellular phone systems are optimized for speech signals and the radio transmission may be 
subject to relatively high error rates, the transmission of text telephone modem signals via the speech path in cellular 
networks is in some cases unsatisfactory: i.e. received messages show an unacceptably high character error rate (CER). 
One reason for this is that the digital cellular phones use speech coding in order to compress the signal. Since this 
coding is optimized for speech-like signals, modem signals are more or less distorted. A further problem is in the 
transmission errors and the applied error concealment in digital cellular phone systems in case of poor channel 
conditions. The repetition of speech frames results in character errors or even in error propagation. 

The traditional text telephone modulation technique, designed years ago for PSTN lines, was not developed for these 
sophisticated, speech-optimized transmission channels. 

Data transmission methods exist in the wireless services, but for various reasons, a text telephone transmission method 
for the speech path is desired. Two reasons are: 1 : text telephony is acknowledged as a way to contact the emergency 
services, and emergency services in wireless networks are so far only defined for speech calls. 2: Alternating speech 
and text in a call is desired, and one simple way to accomplish that without special service support (like multimedia) is 
by alternating the use of the speech channel. 
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5.1 US regulatory issues 



The FCC under the US Government has required an urgent solution for all emergency (911) calls for one specific text 
telephone protocol of the ITU-T V.18 standard, called "Baudot Code". This TS addresses these FCC requirements and 
this section points out specific US regulatory issues. 

The minimum performance requirements for the CTM transmission are included in [1]. That specification shall be 
applied for verifying performance. 

The FCC requires that the solution for cellular systems is fully compatible to traditional text telephone standards, at 
least it shall support Baudot modulation at 45.45 baud in the landline end. 



6 The Goals and Objectives 

CTM is developed to provide a solution that: 

• meets the FCC Emergency Call (911) requirements for Text Telephony; 

• meets the requirements for a Global solution for Text Telephony; 

• works with GSM AMR, EFR, and FR codecs, as well as future codecs; 

• is applicable for existing and future speech traffic channels in GSM and UMTS; 

• minimizes the impact to existing or future cellular networks; 

• allows roaming between networks of different operators; 

• provides a transmission rate of 10 characters per second according to a net bit rate of 80 bit/s; 

• does not introduce an additional delay of more than 800 ms for text transmission; 

• does not have any impact for voice transmission, i.e. speech signals must not be distorted or delayed. 

7 Text Telephony Architecture based upon CTM 

An overall architecture for supporting traditional text telephone communication via cellular telephone systems is 
depicted in Figure 1. This Technical Specification covers the gray shaded transmission and receiving parts of the 
Cellular Text Telephone Modem (CTM). The text telephone detector may act as specified in V.18 [2]. 

This section provides an overview of the CTM transmitter and the CTM receiver. The Cellular Text Telephone Modem 
is fully specified in the following sections. The ANSI C-Code for a bit-exact implementation is provided in [3]. 
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Figure 1 - One Text Telephony Architecture using CTM 

(a) traditional text telephone on both subscribers' sides, CTM acts as a 
signal adaptation device between text telephone code and CTM signals 

(b) alternative solution for the mobile subscriber's part 
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7.1 Text Telephone Devices 



Text telephone devices are text-based terminals that allow the users to communicate by text, character by character via 
telephone networks. A text telephone device for PSTN consists of a keyboard, a text-oriented display and a modem, 
which transforms the text telephone characters into audio signals that can be transmitted via the telephone network. The 
protocols used by text telephone devices vary regionally. The major formats supported with text telephone devices are 
described in ITU-T V.18, reference [2]. 

7.2 Error resilient transmission in the speech path 

The CTM transmitter transforms the text telephone characters into a signal that can be transmitted robustly via the 
speech codec and the radio transmission path of cellular phone systems. The corresponding CTM receiver decodes the 
signal back into text telephone characters. CTM signals are audio signals, which can be transmitted into the analogue 
domain or coded into PCM samples. Therefore, there is no requirement that the CTM and the speech encoder or 
decoder have to be physically integrated. 

The text characters are coded in ISO 10 646-1 UTF-8 [6] according to ITU-T T.140 [5] for the transmission via the 
CTM link. 

7.3 Interworking with Traditional Text Telephone Devices 

Figure 1 (a) shows the situation that either side of the call has a traditional text telephone, which sends and receives 
speech and modem signals alternately in analog or PCM coded form. Therefore, an interworking function is needed to 
detect and to regenerate the modem signals for these traditional text telephones. This interworking function is called 
"text telephone detector/regenerator" here. For PSTN text telephone interworking, the text telephone 
detector/regenerator can be based on V.18 to cover all major text telephone systems worldwide or be made specific to 
the text telephone protocol supported. Within North America the text telephone detector/regenerator may be limited to 
detecting and regenerating Baudot code. 

The text telephone signal can be adapted for use over the radio interface by a combination of a text telephone detector 
and CTM transmitter at one end and a corresponding CTM receiver and text telephone regenerator at the other end. On 
the mobile subscriber's side, this adaptation might take place in a) an external adapter (analog in / analog out), which 
connects the text telephone to the mobile phone, or b) might be integrated into the mobile phone or c) into the text 
telephone device itself. For the PSTN subscriber's side, the signal adaptation has to take place in the network in order to 
guarantee interworking with existing, traditional PSTN text telephone devices. Note that both signal adaptation devices 
- on the mobile subscriber's side as well as on the network side - are functionally identical. In case of several CTM 
adapters in the speech path the unnecessary ones are negotiated into passive mode. In this rare case there exists a 
possibility of a few corrupted or lost characters during negotiation. 

The signal adaptation devices in Figure 1 (a) remain in a passive (transparent) mode, if there are no text telephone 
characters to transmit. For the uplink at the mobile subscriber's part, the CTM transmitter generates a zero-valued 
output signal and both switches SI and S3 are closed as long as the text telephone detector does not receive a traditional 
text telephone modem signal. For the downlink at the mobile subscriber's part, the text telephone regenerator creates a 
zero-valued output signal and both switches S2 and S4 are closed as long there is no valid CTM signal at the CTM 
receiver's input. This guarantees that any other audio signal (e.g. speech) can pass in both directions without any 
modification. This allows the users to transmit speech and text alternately ("Voice Carry Over/Hearing Carry Over 
(VCO/HCO)"). 

An alternative implementation for the mobile subscriber's side is shown in Figure 1 (b). Instead of a traditional text 
telephone, this implementation uses a text conversation user interface (e.g. keyboard and display) that is connected 
directly digitally to the CTM transmitter and receiver. 

For interworking with PSTN text telephones on either side of the connection, the following functionality may be 
provided. The peripheral functions, which have to be added to the CTM functional blocks for supporting text telephone 
interworking, are described in ITU-T V.18. Reference [2] specifies general methods for detection of text telephone 
signals on the Modem side. ITU-T T.140 [5] specifies a common general text conversation format. Together these 
Recommendations should be used to provide translation between legacy modes and the common format.. 

For digital Text Telephone methods, such as IP text telephony, similar functionality can be arranged. 
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ITU-T H.248 Annex F [7] describes packages for addition to the general Gateway protocol H.248 for text telephony, 
text conversation and call discrimination. It describes the control of detection/translation mechanisms that may be 
applied.. 



8 



Technical Description of CTIVI 



8.1 



Overview 



The Cellular Text Telephone Modem allows a reliable transmission of text characters via the speech channel of cellular 
phone systems. The structures of the CTM transmitter and receiver are depicted in Figure 2. The specification of the 
Cellular Text Telephone Modem holds for implementations on the mobile side as well as for the network side. 
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Figure 2 - Overview of the CTM Transmitter and Receiver 

The CTM transmitter expects text input with the character encoding according to the international character set 
ISO 10646-1. It performs character encoding, FEC error protection, insertion of synchronization information, 
interleaving and modulation. Additionally, the CTM signal is periodically suspended and the output is muted in order to 
avoid a condition where any voice activity detectors inside the cellular phone system might classify the modem signal 
as non-speech. In case there is nothing to transmit (i.e. no text input present), the CTM modulator generates a 
zero-valued output signal and the switch SI is set to the 'closed' position so that a speech or audio signal can bypass the 
CTM transmitter. 

At the receiving end, the CTM signal is detected and decoded by the corresponding functions of the CTM receiver. The 
decoded characters are available at the CTM receiver's "text" output, again in ISO 10646-1 encoding. If the CTM 
demodulator does not detect a CTM signal, the speech or audio signal coming from the speech decoder is forwarded via 
the switch S2 to the "speech" output of the CTM receiver in order to support alternating between text and voice.. 



8.2 



CTIVI Transmitter 



The CTM transmitter is described in detail and a bit exact C-code is provided in [3]. 

8.2.1 Character Set 

For the transmission via the radio link, the characters are coded in 8 bit representation according to ISO 10646-1 in 
UTF-8 transform (see ITU-T T.140). The bits that correspond to one character are transmitted sequentially to the FEC 
error protection starting with the least significant bit. No start or stop bits are used at this point. 

8.2.2 FEC Error Protection 

The net bits are protected against transmission errors by means of an r=l/4 convolutional coder with the constraint 
length K=5. The structure of the encoder is depicted in Figure 3. The net bit-stream (with net bits that are either or 1) 
serves as input signal for four FIR filters with the impulse responses 
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gi = {l,0, 1,0, 1 } 

g2={l,0, 1, 1, 1 } 
g3={l, 1,0, 1, 1 } 
g4={l, 1, 1, 1, 1 } 

The convolution of the filters is executed using mod-2 arithmetics, i.e. the output signals of the filters are given by 

"i(^) = KetC^) + ^netC^ - 2) + b^ExC^ -4)] mod 2 

i^iik) = [Vt(^) + ^netC^ - 2) + b^ExC^ - 3) + b^ExC^ - 4)] mod 2 

u^(k) = [^net(^) + bNExC^ -1) + bNExC^ -3) + h^j,j(k-4)] mod 2 
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W4(^) = [Vt (^) + ^netC^ - 1) + ^netC^ - 2) + h^j,j(k - 3) + bf^g^ (/f - 4)] mod 2 , 
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where the mod-2 operation denotes the remainder of a division by two. The output gross bit-stream is obtained by 
merging the four output signals by means of the rotating switch in Figure 3, so that each net bit is mapped to four gross 
bits according to 
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The convolutional encoder is set to its initial state (i.e. all filter states are filled with zeros and the rotating switch is set 
to the Ui-position) each time that a new burst is initiated (see Section 8.2.3, "Burst Structure"). During a running burst 
the convolutional encoder generates the gross bit-stream as described before. At the end of a burst, the convolutional 
encoder is flushed by inserting K-l=4 zero-valued tail bits resulting in (K-l)/r=16 additional gross bits at the encoder's 
output. 
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Figure 3 - Structure of the convolutional encoder 

8.2.3 CTM Burst Structure 

For the CTM signals, a synchronous transmission is used, which is organized in bursts. A burst is initiated as soon as 
there are bits available coming from the block "UTF-8 character encoding". At the beginning of each burst a preamble 
is transmitted, which can be used at the receiving side for the synchronization of the deinterleaver and the error 
correction. Each burst is kept active as long as the block "Mute + AddResynclnfo" is able to transmit bits to the 
interleaver. During the whole burst, the synchronism is kept, i.e. the bits are transmitted at a fixed rate of 400 bit/s, 
according to a duration of 5 ms per pair of two bits. 

The generation of the preamble at the beginning of each burst is described in Section 8.2.5. Since the preamble is 
located at the interleaver' s dummy elements, the transmission of the preamble does not introduce any additional delay. 
Before the first bits of a new burst are passed from the interleaver to the CTM modulator, a sequence {0,0, 1,0, 
1,1, 0,1} should be passed to the modulator. This sequence triggers the modulator to generate a sequence of four 
tones with the frequencies 400 Hz, 800 Hz, 1000 Hz, and 600 Hz, to simplify the initial synchronization of the 
demodulator at the receiving side. 
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The CTM burst is kept active as long as the block "Mute + AddResyncInfo" is able to transmit bits to the interleaver. If 
the bit-stream towards the interleaver is running out, because there are no more characters that have to be transmitted, 
one <IDLE> character (see Section 9.1) is sent from the block "UTF-8 character encoding" to the FEC error 
protection. This insertion of < IDLE > characters can be repeated up to four times, if there are still no regular characters 
available at the text input of the CTM transmitter. The burst is terminated if five <IDLE> characters have been 
transmitted consecutively without any regular characters in between. 

For the termination of the burst, it must be guaranteed that all bits, which are still stored in the buffers of the FEC error 
protection and the interleaver, are transmitted to the far-end side. 

8.2.4 PeriocJic Muting and Insertion of Resyncinronization Sequence 

In order to guarantee that the CTM signal can be reliably transmitted via any kind of speech codec, a periodic muting of 
the transmitted signal is applied that prevents that the modem signal is classified as non-speech by the speech encoder's 
VAD. The functional goal of the process described here is to insert muting intervals of 80 ms with a periodicity of 960 
ms. Furthermore, the transmitted bit-stream provides a training sequence that allows a resynchronization after an 
interrupted transmission, e.g. a cell hand-over. 

The periodic muting and the insertion of the resynchronization information is applied to the bit-stream between the FEC 
Error Protection and the interleaver. Both functions are implemented by means of two switches, as it is indicated in 
Figure 4. The control of the two switches depends on the value of the index k, which is the time index of the bit-stream 

^muted(^^ ■ T^i^ bit-stream contains the information bits coming from the FEC error protection as well as the bits that 

are inserted and marked as to be muted. 



FEC Error 
Protection 



Periodic IVluting 
bFEc(i) 



Muted 
Bits 



ke [ku 



Insert Resync Sequence 

OmutedW bouiil) 



Resync 
Sequence 



k = Nn 



Interleaver + 
Sync Preamble 



Figure 4 - Periodic muting and insertion of resynchronisation sequence 

The default position of the first switch is such that the bits coming from the FEC error protection are forwarded to the 

next block. Only for certain indices kf^yj^ , which are stored in a look up table, the first switch is set to its lower 

position in order to insert a "mute bit". In this case, the bit that is actually available from the FEC error protection is 
maintained until the switch is in its default position again. Therefore, the switch acts as an insertion device so that no bit 
coming from the FEC error protection is discarded. 

The indices kf^yj^ , which indicate at what time instants a "mute bit" has to be inserted, are stored in a look up table. 
The indices can be calculated as follows: 



^MUTE 



= 5-1 + n-B + m(BD-l) with 0<n<4, 0<m<B and 5 = 8, D = 2 



This results in the following indices: 

07, 22, 37, 52, 67, 82, 97, 112, 

15, 30, 45, 60, 75, 90, 105, 120, 

23, 38, 53, 68, 83, 98, 113, 128, 

31, 46, 61, 76, 91, 106, 121, 136. 

As can bee seen in Figure 6, these bits are consecutive in the bit-stream after the interleaver and therefore generate a 
silent period of 80 ms. 
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The second switch is also controlled by the actual value of k. In case that k is equal to A^g^^Kvc = 352 , all 32 bits of 

the resynchronization sequence ^g^^Kvc are inserted. Similar to the first switch, also this switch acts like an insertion 

device, so that all bits coming from the previous block are maintained. After the insertion of the resynchronization 
sequence, the index k is reset to zero in order to obtain a periodic muting and resynchronization with a periodicity of 
352+32=384 bits. The organization of the resulting bit-stream that is sent to the interleaver is depicted in Figure 5. 

The resynchronization sequence S^^^^ync consists of 32 elements: 

Sresync ~ I 0, 1, 0, 1, 0, 1, 1, 0, 

0, 1, 1, 0, 1, 1, 1, 0, 

1, 1, 0, 1, 0, 0, 1, 0, 
0, 1, 1, 1, 0, 0, 0, 1.} 
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Figure 5 - Organization of the bit-stream boui to the interleaver 
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8.2.5 Interleaver and Synchronization Preamble 

The operation of the interleaver can be understood as a buffer that is organized in a two-dimensional matrix with 
B —S columns. The bits coming from the block "Mute and Add Resynclnfo" are written into this matrix in a diagonal 
way using an interlace factor of D = 2 (diagonal arrows in Figure 6). The interleaved bits are read out from the matrix 
horizontally row-by-row, as indicated by the horizontal arrows in Figure 6. 

The interleaver applies an additional scrambling to all bits that are written into the buffer. For this scrambling, an XOR 
operation between the incoming bits and the scrambling sequence 

s,rAi) = {1,0,1,1, 0,0,1,1}, 



which is repeated periodically, is used. Therefore, all bits that are stored in columns #0, #2, #3, 
inverted. This scrambling is compensated at the far-end side. 
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Figure 6 - Interleaver matrix and location of the preamble 

Therefore, the interleaver does a mapping between the incoming and outgoing bits according to 

bourik) = bj^d) xor SscR(irnodB) 

in such a way that an incoming bit with index / is mapped to a position with index 
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)t = (z mod 5) ■ (5D + 1) + 5 ■ floor 



^•^ 



in the outgoing bit-stream. In these equations, the mod-B operation represents the remainder of a division by B and the 
function floor() denotes "round towards -oo". 

As it is indicated in Figure 6 by the elements marked by "x", the interleaved bit-stream contains several dummy bits, 
which do not correspond to any of the incoming bits. These dummy positions, which occur at the beginning of a burst, 
are filled with the elements of the preamble, which can be used at the receiver side for synchronization purposes. The 
elements of the preamble are stored row-by-row into the positions marked with "x" in Figure 6 without applying the 
scrambling operation that was described previously, i.e. the scrambling is applied only to the bits that are coming from 
the block "Mute and Add Resynclnfo". The preamble, which consists of 

_ B{B-l)D _ 

'^^ PREAMBLE ^ ■-"-' 

elements, is stored in all elements bp^j (k) with k fulfilling the relation 

k = lB + mDB + n with /e {0,1}, me {0,1, 2,3,4,5,6}, ne {m + l,...,l} . 
The preamble consists of 56 elements: 

SpREAMB ~ { 0, 1, 0, 1, 0, 1, 1, 0, 

0, 1, 1, 0, 1, 1, 1, 0, 

1, 1, 0, 1, 0, 0, 1, 0, 
0, 1, 1, 1, 0, 0, 0, 1, 
0, 1, 1, 1, 1, 0, 0, 1, 
0, 1, 0, 0, 0, 1, 1, 0, 
0, 0, 0, 1, 0, 0, 0, }. 



Because the preamble has an auto-correlation function with a distinct maximum if a bipolar representation according to 

■^BIPOLAR VU ~ ^ ■ ■^PREAMB V)~ ^ 

(i.e. each zero-valued element of the unipolar sequence S preamb (^) ^^^ '■° ^^ mapped to a "-1") is used, the preamble 
allows a reliable synchronization of the deinterleaver and the FEC error correction at the receiver side. The 
synchronization can be achieved by calculating the cross-correlation between the received bit-stream and a copy of the 
preamble at the receiver side. The correct time alignment can be found by comparing the actual cross-correlation with 
an implementation-dependent threshold value. 

As long as there are no bits available from the block "Mute + AddResyncInfo", the interleaver is in idle mode. 
Therefore, no bits are transmitted to the CTM modulator, so that the CTM modulator generates a zero-valued audio 
signal. 

As soon as there are bits available coming from the block "Mute + AddResyncInfo", a burst is initiated. This means that 
the appropriate elements of the interleaver buffer are initialized with the elements of the preamble. After this 
initialization, the incoming bits are stored into the interleaver buffer and the outgoing bits are read out from the 
interleaver buffer as described previously. 

For the termination of the burst, it must be guaranteed that all bits, which are still stored in the interleaver' s buffer, are 
transmitted. For this flushing of the interleaver, A^^^ = [B — I)- D ■ B elements are read-out from the interleaver 
while the same number of zero-elements is written into the interleaver. After this flushing of the interleaver at the end of 
a burst, the interleaver returns into idle mode again, so that the CTM modulator becomes inactive and produces a 
zero-valued output signal again. 
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8.2.6 CTM Modulator 

The bit-stream coming from the interleaver is grouped in pairs of two bits. Each pair of two bits is modulated into a sine 
waveform of length 5 ms (40 samples) starting with a phase value of zero. The relation between the bits and the 
modulated waveform is as follows: 



s(k) = 8 • round 



2047 ■ sin 



iTT- 



f 



8000 



for < A: < 40, 



yj 



where it is assumed that the audio samples are PCM-coded with 2's complement representation and with a resolution of 
13 significant bits, left -justified in a 16-bit word. The three least significant bits are set to '0'. The amplitude is set to a 
value lower than maximum in order to avoid saturation of speech codecs within the transmission path. 

Depending on the values of the bits bitO/bitl, one of the frequencies 400 Hz, 600 Hz, 800 Hz, and 1000 Hz is used, 
provided that at least one of the two bits is not marked as to be muted. In case that both bits bitO and bitl are marked to 
be muted, a sequence of 40 zero-valued samples is generated. 

The output signal is also zero in case that no valid bits are available at the CTM modulator's input. 
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Table 1: Frequency parameter/ for the CTM modulator 

8.2.7 Switching between Speecin and Data 

The Cellular Text Telephone Modem includes an adaptive switching between CTM signal generation and the 
transparent transmission, if there are no text characters for transmission. This automatic switching is provided in both 
directions by means of the switches S 1 and S2 in Figure 2. 

Switch S 1 is controlled by the functional blocks of the CTM transmitter with the intention to avoid forwarding the 
signal from the speech input of the CTM transmitter while the CTM modulator is active. The default position of switch 
S 1 is its "closed" position so that the signal at the "speech" input of the CTM transmitter can bypass without 
modification as long as the CTM modulator is in idle mode. Switch SI is set to its "open" position if the CTM 
modulator is active, i.e. the output signal of the modulator is not zero. 

Switch S2 is controlled by the functional blocks of the CTM receiver with the intention to block any CTM signal. The 
default position of switch SI is its "closed" position so that the CTM receiver's input signal can bypass to the "speech" 
output. Switch S2 is set to its "open" position as soon as the CTM receiver has detected a CTM sequence. Switch S2 
remains in its "open" position as long as the receiver has not detected the end of the CTM burst. 



8.3 



CTM Receiver 



One possible implementation of the CTM Receiver is provided in Annex A for guidance. No normative bit exact C- 
code is provided in order to allow implementation freedom and further improvements. Test sequences and minimum 
performance requirements for the CTM receiver are provided in [ 1 ] . 



9 CTM Negotiation and Inband Signaling 

An inband signaling procedure for CTM negotiation is specified. It shall be used to verify that CTM functionality is 
(still) available at the far-end side. 
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A control character may be inserted into the character stream at any position, i.e. control characters may be preceded or 
followed by text characters. The CTM receiver shall detected and remove these control characters from the text stream. 

9.1 Definition of Control Characters 

The following two control characters and functions are defined: 

<ENQUIRY>, value 0x05. Used to request a CTM acknowledgment burst from the far-end side (at the other side of the 
radio link) in order to detect, whether it is able to support CTM signals. 

<IDLE>, value 0x16. Used as filler when the continuation of the ongoing burst is wanted, but no character is available 
for transmission, e.g. because the user makes a small pause in typing. 

9.2 CTIVI Availability Negotiation 

A CTM device shall permanently monitor its CTM receiver input for the potential occurrence of a CTM burst. 

As soon as text input is detected for the first time by a CTM transmitter, or if it is in any other way detected that text 
conversation is required, the CTM availability negotiation shall be initiated. A CTM burst shall be generated that shall 
contain the <ENQUIRY> character at the beginning and may contain further regular text characters, control characters 
or none. 

When a CTM burst is received the first time or a CTM burst is received with an <ENQUIRY> character, the CTM 
device shall immediately respond with another CTM burst to acknowledge that CTM is supported. This CTM 
acknowledgement burst might be empty, respectively might contain only <IDLE> characters, if there are no regular 
characters to transmit. If a CTM burst is already ongoing, then no additional CTM burst is required. 

If the initiator of the CTM enquiry burst does not receive any CTM burst within 1320 ms after the start of the 
transmission, it shall repeat the enquiry burst for a maximum of 2 times. If there is still no acknowledgement received, 
then it shall assume that CTM is not available at the far end and shall go into transparent mode in both directions, until a 
potential CTM burst is received eventually. 

The enquiry burst can be used at any time during the session to verify that CTM availability is intact. This can be done 
periodically, or after detection of an event that may indicate that CTM support is lost at the other end. One of such 
events may be the loss of synchronization due to switching of the voice path to another CTM device. 



10 Functions in the CTIVI environment 

This section gives a summary of the behavior of the CTM communication in case of an interruption in the 
communication, restart or rerouting during the call. Different CTM network architectures are possible and they have 
different behavior in these cases. 

1 0.1 CTM to CTM communication 

If both ends of the text conversation support CTM communication, then no further support within the network is 
necessary. The communication is robust and requires just an ordinary speech path. Even mobile-to-mobile 
communication will in nearly all situations be satisfyingly robust. Typically neither side of the communication is 
replaced during the call. 

Short interruptions of the CTM channel and changes of the signal delay between the CTM partners may occur due to 
cell handover of the mobile system. If no CTM communication is ongoing during the handover, then no effect is visible 
at all. Otherwise, if a CTM burst transmission is ongoing during the handover, then resynchronisation, interleaving and 
FEC error correction will eliminate most or all of the effects on the output character stream, since the CTM 
communication resides outside of this cellular handling. At the latest, the next CTM burst will be in good shape again. 

In few cases supplementary services like "call on hold", "call forwarding", "conference call" or others may be applied. 
Depending on these services text transmission may be influenced, but not more than in ordinary land based text 
telephony. 
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Since the CTM communication is end-to-end and no network support is needed, roaming of the mobile side to any other 
network is always possible. As long as the speech path is good enough even a change of the mobile system technology 
will be possible. 

1 0.2 CTM between the mobile side and a Gateway 

In this scenario, where the CTM device on the network side is placed within a gateway to perform the adaptation 
between CTM and a traditional text telephone standard, typically neither side of the CTM communication (mobile and 
gateway) is replaced during the call. CTM re-negotiation is then not necessary. The unprotected traditional text 
telephony signal is completely unaffected by all handovers. 

CTM interruption and signal delay variation due to cell handover is handled exactly as described above in 10.1. Same 
holds for supplementary services etc. 

Text Telephony users roaming in other networks that do not provide CTM Gateways will have still unrestricted CTM 
communication with other CTM users, either on the mobile or the fixed side. When the home environment is provided 
also to the roaming user, then he is able to use the CTM-Gateway of his home network (the call is automatically routed 
through that CTM-Gateway) and he can communicate with all users of traditional text telephones as within his home 
network. 

10.3 CTIVI within the Transcoding Equipment 

In this scenario the CTM on the network side is integrated into the transcoding equipment. Since the FCC requires 
100% reliable 911 emergency calls, it seems to be obvious that all transcoders within a network must be equipped with 
CTM functionality, or text telephone calls need to be identified and routed though these specifically equipped 
transcoding equipment. The effects on character transmission are similar to the cases described above in 10.1 and 10.2, 
as long as the transcoding equipment is not replaced during handover. 

But when this transcoding equipment (and therefore the CTM device as well) is replaced during cell handover, then 
more adverse effects may occur. 

If no CTM communication was ongoing at the moment of handover, then no major effect is visible. The newly invoked 
CTM device will either receive first a CTM burst from the mobile side: then it knows that CTM is available. Or it 
receives first text input from the network side: in this case it will insert an <ENQUIRY> character to trigger a CTM 
acknowledgement. After that normal CTM communication continues. 

If a CTM burst was ongoing at the moment of handover, then part of the CTM burst in uplink is received by the old 
transcoder and the other part by the new transcoder. Depending on the length of the handover interruption and the 
specific transcoder architecture (which is not standardized), some of the text characters up to the full CTM burst may be 
corrupted or lost. The unprotected traditional text telephony signal is in this scenario also affected by the handover. 
Similar error effects occur in downlink. The next CTM burst will, however, be received with good quality. 

1 0.4 Cascading of CTIVI Adapters in the Speech Path 

Due to various reasons it might happen that more than one CTM adapter is placed into the speech path. One example is 
a Mobile-to-Mobile call with CTM at both ends, but with one CTM adapter on each radio leg. Another example may be 
when a text telephony user has traditional equipment and starts to use CTM by buying a "smart cable". He will be able 
to use his old text telephone and his old mobile device and just connects them with the cable to get CTM functionality. 
Later he might decide to buy a new CTM based text telephone, but he forgets to replace the smart cable. Now he has 
two CTM devices in cascade on the mobile side. 

The CTM devices within the path will in these cases never receive a traditional text telephony signal from either side 
and will therefore stay in transparent mode in both directions. Effectively only two CTM partners are active in all cases. 

1 0.5 Rerouting of a call from a CTM supported environment to a 
non-supported environment 

Due to the FCC requirement for ubiquitous text telephony support for 911 emergency calls this scenario is unlikely to 
occur in ordinary cell handovers. 
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If, by any reason, a call is rerouted during a CTM session into an environment where CTM is not supported, there is a 
risk of a period of text loss. If the mobile station continues to transmit CTM signals, the network base traditional text 
telephony device will not be able to decode it after the rerouting. The CTM at the mobile side will, however, receive 
suddenly traditional text telephony signals and will pass them transparently through. It may also detect this event. The 
use of the <ENQUIRY> burst as described above for re-negotiation is a method to discover the disruption in the CTM 
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Annex A CTM Receiver (Informative) 

The following example implementation of a CTM receiver is provided for guidance. 



A.1 



Demodulator 



The CTM Demodulator works on a frame-by-frame basis with a nominal frame length of 40 samples. Due to the fact 
that the demodulator synchronizes itself permanently on the incoming bit-stream, the instantaneous frame length might 
be 39, 40, or 41 samples. The structure of the CTM demodulator is shown below. 
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Figure A.l - Structure of the CTM demodulator 

The received CTM signal is filtered by means of four band-pass filters (BP) with the frequencies 400 Hz, 600 Hz, 
800 Hz, and 1000 Hz. The output signals of the band-pass filters are rectified and low-pass filtered (LP). The output 
signals of these low-pass filters can be understood as the envelopes of the band-pass filters. These envelope signals are 
used for updating the sampling instant, which takes place 39, 40, or 41 samples after the last sampling instant. This 
tracking is made in such a way, that the sampling takes place at time instants where the differences between the four 
envelope signals are as great as possible. Finally, for each frame of 39, 40, or 41 samples, a pair of two bits is decoded 
depending on the decision, which of the four band-pass channels contains the maximum energy. The decoded bits 
contain soft information about the security of the decision. This reliability information depends on the magnitude of the 
difference between the envelope signals as well as on the ratio between the band-pass envelope signals and the 
broad-band envelope signal, which is processed in the fifth branch (the lowest signal path in Figure A.l). 

A.2 Synchronization and Deinterleaver 

The deinterleaver is the inverse operation of the interleaver and can be implemented accordingly. 

The synchronization of the deinterleaver is based on the preamble that has been generated by the interleaver at the 
dummy positions as described in Section 8.2.5. Due to the special characteristics of the preamble's auto -correlation 
function, the synchronization is based on calculating the cross-correlation function between the bit-stream coming from 
the CTM demodulator and a copy of the preamble, which has been used at the transmitter side. Since the bipolar 



sequence ^gipo^AR 



2- Sr 



, (/) — 1 has an auto-correlation function with a very distinct maximum, the correct 



time alignment can be easily found by comparing the actual cross-correlation with an appropriate threshold value. 

This regular synchronization of the deinterleaver might fail for several reasons. One reason might be an extremely weak 
radio channel, which prevents a correct detection of the preamble due to a high bit error rate. A second reason might be 
a cell handover between two transcoders, while an CTM burst is active. In either case the initial burst might not be 
received causing loss of synchronization. 
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In order to recover synchronization, the receiver is equipped with back-up synchronization. This back-up 
synchronization is based on the detection of the resynchronization sequence (see Section 8.2.4). The resynchronization 
sequence has similar auto-correlation properties than the preamble, which allows detecting the resynchronization 
sequence by means of correlation techniques. If the receiver detects this resynchronization sequence while it is in idle 
mode, it changes into active mode. 



A.3 Puncture and Resynchronization 



This function eliminates the bits of the resynchronization sequence as well as the muted bits from the bit-stream. This 
puncturing is based on look-up tables, which contain the bit positions that refer to resynchronization or muted bits. 

The resynchronization is used for detecting non-constant time delays on the speech traffic channel, which might occur 
after a cell hand-over. The detection of the correct alignment is also based on a cross-correlation between the received 
bit-stream and a copy of the resynchronization sequence that has been inserted at the transmitter side. The 
resynchronization detects non-constant delays that lead to a misalignment of up to ±14 bits due to variations in the time 
delay of up to ±35 ms. 

A.4 FEC Error Correction 

The channel decoder, which corresponds to the convolutional encoder described in Section 8.2.2, is based on the Viterbi 
algorithm. The Viterbi algorithm may use "Soft Decisions" in order to exploit the soft information, which is coded in 
the magnitude of the bits generated by the CTM demodulator. Typically, the Viterbi algorithm introduces a delay of 
5-K=25 net bits for the decoding process. 

The Viterbi algorithm is (re-) initialized in the same moment as the deinterleaver switches from idle mode into active 
mode. The Viterbi algorithm is executed as long as the burst is running and as long as there are bits coming from the 
block "Puncture-H Resynchronization" . 
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